Field of the Invention
The present invention relates to a method for generating an FPGA implementation based on an FPGA design serving as an FPGA model and/or a hardware description, comprising the steps of synthesizing a net list from the FPGA design, and generating the FPGA implementation based on the net list, wherein the method comprises searching for a similar FPGA implementation, and the step of generating the FPGA implementation from the net list is done using the similar FPGA implementation.
Description of the Background Art
Furthermore, the invention relates to a method for generating a bit stream based on an FPGA design serving as an FPGA model and/or a hardware specification, including the above steps for generating an FPGA implementation based on an FPGA design serving as an FPGA model and/or a hardware description, and the generation of the bit stream based on the FPGA implementation.
Such methods are used to generate code for FPGAs (Field Programmable Gate Array). FPGAs are integrated circuits to which a logic circuit can be loaded. In contrast to classical programming in a known programming language, rather than including preset timed sequences, it includes the definition of the desired circuit pattern.
An FPGA design for defining the desired circuit pattern is typically generated as a graphical FPGA model, which is translated into a hardware description language such as VHDL. In principle, the FPGA design can also be generated directly in the hardware description language.
In a synthesis step, the FPGA design is first translated by a corresponding software into a net list that specifies how individual logic elements are to be interconnected in the FPGA. One therefore speaks of the configuration of an FPGA. The net list with the logic elements and their interconnection is stored for future use.
This is followed by a step to create the FPGA implementation. This step is commonly referred to as “place and route”. In this context, the logic elements stored in the net list are placed for the FPGA (place) and connected according to the net list (route). The result is the FPGA implementation.
Following, a bit stream is generated based on the FPGA implementation, which is transferred to the FPGA in order to implement a desired function therein.
The above steps are often summarized as a “build”.
Nowadays, there are easy-to-use tools that provide, for example, an abstracting FPGA development environment for clients so that clients can develop their own hardware without detailed knowledge of FPGAs and tool flows. Clients can thus create and implement FPGA designs and operate these in a corresponding FPGA hardware, the FPGA. Regular modifications to the FPGA model with a subsequent re-build are a natural part of such a development process, e.g., in rapid control prototyping.
Often, one problem in this regard is very long build times, which may also be needed to rebuild an FPGA with even a minor modification in the FPGA model. The build times often range a number of hours. Since the FPGAs are becoming more and more complex and provide more resources in the form of registers, logic, DSP blocks or memory, build times continue to increase. This can only be partially compensated by algorithm improvements and faster machines to perform the build. A particularly time-consuming step is usually the placing and routing.
In the current FPGA tools, there are two approaches to reduce the build times. Both approaches are based on the fact that unmodified regions/components of an already successfully-generated FPGA implementation are reused. In the first approach, each component is assigned a (rectangular) region in the FPGA. When a component is modified, the region with this component is newly implemented, while the remainder of the FPGA implementation remains unmodified and can be reused. The second approach, referred to here as an incremental build, does not require any predefined regions. For implementation, an already implemented FPGA implementation is given as a reference. If there is a match to a high degree, many placements and routings can be automatically adopted and the time for generating the FPGA implementation is reduced.
It may be advantageous if an FPGA implementation is generated from the start in a way that individual modules or partial implementations can be reused. This approach pursues an automatic modularization of the FPGA model. On the basis of this module, floorplanning can take place, i.e., a division into regions. If there are reserves for each module, modifications in the FPGA model can be limited to the individual modules.
In addition, methods for replanning are known. If a client has made modifications to their FPGA model, the latest build result is used. Based on that, modified modules are built individually and then replaced in the overall build. In the event that multiple modules are affected, build times can be reduced if the build for the modified modules takes place on different computers. Thus, a parallel build of the modified modules is carried out. In this case, a versioning of different module versions may be provided in order to facilitate reuse.
Although these methods can reduce build times, there is still room for improvement. For example, in a fine granular modularization, there is great waste and an increased risk of timing violations since it is not possible to optimize over module boundaries and each module must be provided with a generous range, including sufficient reserves. In addition, the method can only be applied with great implementation effort during product development.
To find a similarity between two designs, current synthesis tools compare a reference net list with the net list to be newly placed and routed. The comparison is based exclusively on a name comparison of net list path names. This is problematic because it is common for abstracting, high-level FPGA design tools such as Xilinx Vivado System Generator, Xilinx Vivado HLS, Xilinx Vivado SDSoC, to perform a quick renaming and reorganization of identical FPGA components, e.g., subsystems. This automatically results in new net list paths even for virtually identical components. The renaming cannot be recognized by the current synthesis tools.